home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-madman-networkmib-01.txt < prev    next >
Text File  |  1993-06-21  |  15KB  |  437 lines
  1.  
  2.                             Internet Draft
  3.                     Network Services Monitoring MIB
  4.  
  5.                           MADMAN Working Group
  6.                              June 18, 1993
  7.                        Expires: December 18, 1993
  8.  
  9. Status of this Memo
  10.  
  11. This document is an Internet Draft. Internet Drafts are working
  12. documents of the Internet Engineering Task Force (IETF), its Areas,
  13. and its Working Groups. Note that other groups may also distribute
  14. working documents as Internet Drafts.
  15.  
  16. Internet Drafts are draft documents valid for a maximum of six 
  17. months.    Internet Drafts may be updated, replaced, or obsoleted by
  18. other documents at any time.  It is not appropriate to use Internet
  19. Drafts as reference material or to cite them other than as a "working
  20. draft" or "work in progress."
  21.  
  22. Please check the I-D abstract listing contained in each Internet 
  23. Draft directory to learn the current status of this or any  other
  24. Internet Draft.
  25.  
  26. Abstract
  27.  
  28. This document defines the generic part of a MIB suitable for
  29. monitoring applications which provide some kind of network services.
  30. This MIB is intended to be extended to accomodate monitoring specific
  31. to a given type of service, for example, a Message Transfer Agent
  32. (MTA) service or a Directory Service Agent (DSA) service.
  33.  
  34. Rationale for having an Network Services Monitoring MIB
  35.  
  36. There is a substantial need to monitor applications which provide
  37. network services, particularly distributed components such as MTAs and
  38. DSAs, in order to measure load and to detect broken connectivity,
  39. system failure, congestion, and other types of problems. Specific
  40. requirements include:
  41.  
  42. (1) General monitoring of a large number of components (typical
  43.     for a large organization).
  44. (2) Integration with general network management.
  45.  
  46. SNMP is the clear choice for this function.  At present only simple
  47. read-only access is defined; this is sufficient to determine up/down
  48. status and provide an indication of a broad class of operational
  49. problems.   
  50.  
  51. Restriction of Scope
  52.  
  53. The framework provided here is very minimal; there is a lot more that
  54. could be done. For example:
  55.  
  56. (1) General network service application configuration.
  57. (2) Detailed examination and modification of individual entries in
  58.     service-specific request queues.
  59. (3) Probing to determine the status of a specific request (e.g. the
  60.     location of a mail message with a specific message-id).
  61. (4) Requesting that certain action be performed (e.g. forcing an
  62.     immediate connection and transfer of pending messages to some
  63.     specific system).
  64.  
  65. Whilst all these capabilities are both impressive and useful, to be
  66. effective, security is an absolute requirement. These capabilities
  67. also mandate a much more complex design with many characteristics
  68. likely to be fairly implementation-specific. As a result such
  69. facilities are likely to be both contentious and difficult to
  70. implement. 
  71.  
  72. This document religiously keeps things simple and focuses on the basic
  73. monitoring aspect of managing applications providing network services. 
  74. The goal here is to provide a framework which is simple, useful, and
  75. widely implementable.
  76.  
  77. Relationship to Directory Services
  78.  
  79. Use of and management of directory services already is tied up with
  80. network service application management.  There are clearly many things
  81. which could be dealt with by directory services and protocols.  We
  82. take the line here that static configuration information is both
  83. provided by and dealt with by directory services and protocols. The
  84. emphasis here is on transient application status.
  85.  
  86. By placing static information in the directory, the richness and
  87. linkage of the directory information framework does not need to be
  88. repeated in the MIB.  Static information is information which has a
  89. mean time to change of the order of days or longer.
  90.  
  91. When network service applications that employ directory services
  92. are monitored, it is recommend that a linkage be established, so
  93. that:
  94.  
  95. (1) The managed object contains its own directory name.  This
  96.     allows all directory information to be obtained by reference.
  97.     This will let a SNMP monitor capable of performing directory
  98.     queries present this information to the manager in an
  99.     appropriate format.  It is intended that this will be the
  100.     normal case. 
  101. (2) The directory will reference the location of the SNMP agent,
  102.     so that an SNMP capable directory query agent could probe
  103.     dynamic characteristics of the object.  
  104. (3) This approach could be extended further, so that the SNMP
  105.     attributes are modelled as directory attributes.  This would
  106.     dramatically simplify the design of directory service agents
  107.     that use SNMP to obtain the information they need.
  108.  
  109. Application Objects
  110.  
  111. This MIB starts with a set of general purpose attributes which would
  112. be appropriate for a range of applications that provide network
  113. services.  Both OSI and non-OSI services can be accomodated.
  114. Additional tables defined in extensions to this MIB provide attributes
  115. specific to specific network services.
  116.  
  117. A table is defined which will have one row for each network service
  118. application running on the system.  The only static information held
  119. on the application is its distinguished name.  All other static
  120. information should be obtained from various directory services.  The
  121. Directory Name is an external key, which allows an SNMP MIB entry to
  122. be cleanly related to the X.500 Directory.  In SNMP terms, the
  123. applications are grouped in a table called applTable, which is indexed
  124. by an integer key applIndex.
  125.  
  126. The type of the application will be determined by one or both of:
  127.  
  128. (1) Additional MIB variables specific to the applications.
  129. (2) An association to the application of a specific protocol.
  130.  
  131. APPLICATION-MIB DEFINITIONS ::= BEGIN
  132.  
  133. IMPORTS
  134.   OBJECT-TYPE FROM RFC1212
  135.   experimental, Counter, Gauge, TimeTicks FROM RFC1151-SMI
  136.   DisplayString FROM RFC1213-MIB;
  137.  
  138. application-mib OBJECT IDENTIFIER ::= {experimental xxx}
  139.  
  140. applTable OBJECT-TYPE
  141.     SYNTAX SEQUENCE OF ApplEntry
  142.     ACCESS not-accessible
  143.     STATUS mandatory
  144.     DESCRIPTION
  145.         "The table holding objects which apply to all different
  146.          kinds of applications providing network services."
  147.     ::= {application-mib 1}
  148.  
  149. applEntry OBJECT-TYPE
  150.     SYNTAX ApplEntry
  151.     ACCESS not-accessible
  152.     STATUS mandatory
  153.     DESCRIPTION
  154.       "An entry associated with a network service application."
  155.     INDEX {applIndex}
  156.     ::= {applTable 1}
  157.  
  158. ApplEntry ::= SEQUENCE {
  159.     applIndex
  160.         INTEGER,
  161.     applName
  162.         DisplayString,
  163.     applVersion
  164.         DisplayString,
  165.     applOperStatus
  166.         INTEGER,
  167.     applLastChange
  168.         TimeTicks,
  169.     applInboundAssociations
  170.         Gauge,
  171.     applOutboundAssociations
  172.         Gauge,
  173.     applAccumulatedInboundAssociations
  174.         Counter,
  175.     applAccumulatedOutboundAssociations
  176.         Counter,
  177.     applLastInboundActivity
  178.         TimeTicks,
  179.     applLastOutboundActivity
  180.         TimeTicks,
  181.     applRejectedInboundAssociations
  182.         Counter,
  183.     applFailedOutboundAssociations
  184.         Counter
  185. }
  186.  
  187. applIndex OBJECT-TYPE
  188.     SYNTAX INTEGER (1..2147483647)
  189.     ACCESS read-only
  190.     STATUS mandatory
  191.     DESCRIPTION
  192.       "An index to uniquely identify the network service
  193.        application."
  194.     ::= {applEntry 1}
  195.  
  196. applName
  197.     SYNTAX DisplayString
  198.     ACCESS read-only
  199.     STATUS mandatory
  200.     DESCRIPTION
  201.       "The name the network service application chooses to be
  202.        known by."
  203.     ::= {applEntry 2}
  204.  
  205. applVersion
  206.     SYNTAX DisplayString
  207.     ACCESS read-only
  208.     STATUS mandatory
  209.     DESCRIPTION
  210.       "The version of network service application software."
  211.     ::= {applEntry 3}
  212.  
  213. applOperStatus OBJECT-TYPE
  214.     SYNTAX INTEGER {
  215.       up(1),
  216.       down(1),
  217.       halted(3),
  218.       congested(4),
  219.       restarting(5)
  220.     }
  221.     ACCESS read-only
  222.     STATUS mandatory
  223.     DESCRIPTION 
  224.       "Indicates the operational status of the network service
  225.        application. 'down' indicates that the network service is
  226.        not available. 'running' indicates that the network service
  227.        is operational and available.  'halted' indicates that the
  228.        service is operational but not available.  'congested'
  229.        indicates that the service is operational but no additional
  230.        inbound associations can be accomodated.  'restarting'
  231.        indicates that the service is currently unavailable but is
  232.        in the process of restarting and will be available soon."
  233.     ::= {applEntry 4}
  234.  
  235. applLastChange OBJECT-TYPE
  236.     SYNTAX TimeTicks
  237.     ACCESS read-only
  238.     STATUS mandatory
  239.     DESCRIPTION
  240.       "The value of sysUpTime at the time the network service
  241.        application entered its current operational state.  If"
  242.        the current state was entered prior to the last
  243.        initialization of the local network management subsystem,
  244.        then this object contains a zero value."
  245.     ::= {applEntry 5}
  246.  
  247. applInboundAssociations OBJECT-TYPE
  248.     SYNTAX Gauge
  249.     ACCESS read-only
  250.     STATUS mandatory
  251.     DESCRIPTION
  252.       "The number of current associations to the network service
  253.        application, where it is the responder.  For dynamic single
  254.        threaded processes, this will be the number of application
  255.        instances."
  256.     ::= {applEntry 6}
  257.  
  258. applOutboundAssociations OBJECT-TYPE
  259.     SYNTAX Gauge
  260.     ACCESS read-only
  261.     STATUS mandatory
  262.     DESCRIPTION
  263.       "The number of current associations to the network service
  264.        application, where it is the initiator.  For dynamic single
  265.        threaded processes, this will be the number of application
  266.        instances."
  267.     ::= {applEntry 7}
  268.  
  269. applAccumulatedInboundAssociations OBJECT-TYPE
  270.     SYNTAX Counter
  271.     ACCESS read-only
  272.     STATUS mandatory
  273.     DESCRIPTION
  274.       "The total number of associations to the application entity
  275.        since application initialization, where it was the responder.
  276.        For  dynamic single threaded processes, this will be the
  277.        number of application instances."
  278.     ::= {applEntry 8}
  279.  
  280. applAccumulatedOutboundAssociations OBJECT-TYPE
  281.     SYNTAX Counter
  282.     ACCESS read-only
  283.     STATUS mandatory
  284.     DESCRIPTION
  285.       "The total number of associations to the application entity
  286.        since application initialization, where it was the initiator.
  287.        For dynamic single threaded processes, this will be the
  288.        number of application instances."
  289.     ::= {applEntry 9}
  290.  
  291. applLastInboundActivity OBJECT-TYPE
  292.     SYNTAX TimeTicks
  293.     ACCESS read-only
  294.     STATUS mandatory
  295.     DESCRIPTION
  296.       "The time since this application has had an inbound
  297.        association."
  298.     ::= {applEntry 10}
  299.      
  300. applLastOutboundActivity OBJECT-TYPE
  301.     SYNTAX TimeTicks
  302.     ACCESS read-only
  303.     STATUS mandatory
  304.     DESCRIPTION
  305.       "The time since this application has had an outbound
  306.        association."
  307.     ::= {applEntry 11}
  308.  
  309. applRejectedInboundAssociations OBJECT-TYPE
  310.     SYNTAX Counter
  311.     ACCESS read-only
  312.     STATUS mandatory
  313.     DESCRIPTION
  314.       "The total number of inbound associations the application
  315.        entity has rejected, since application initialization."
  316.     ::= {applEntry 12}
  317.  
  318. applFailedOutboundAssociations OBJECT-TYPE
  319.     SYNTAX Counter
  320.     ACCESS read-only
  321.     STATUS mandatory
  322.     DESCRIPTION
  323.       "The total number associations where the application entity
  324.        is initiator and association establishment has failed,
  325.        since application initialization."
  326.     ::= {applEntry 13}
  327.  
  328. -- The basic applTable contains a list of the application entities.
  329. -- A second table is maintained, which holds the list of
  330. -- associations.  This is treated as a separate group to the basic
  331. -- application table.  Where simplified appplication monitoring is
  332. -- needed, the assocTable group may be omitted. This table is
  333. -- indexed by applIndex and assocIndex, with the application index
  334. -- coming first.   
  335.  
  336. assocTable OBJECT-TYPE
  337.     SYNTAX SEQUENCE OF AssocEntry
  338.     ACCESS not-accessible
  339.     STATUS mandatory
  340.     DESCRIPTION
  341.         "The table holding a set of all active application
  342.          associations."
  343.     ::= {application-mib 2}
  344.  
  345. assocEntry OBJECT-TYPE
  346.     SYNTAX AssocEntry
  347.     ACCESS not-accessible
  348.     STATUS mandatory
  349.     DESCRIPTION
  350.       "An entry associated with an association for a network
  351.        service application."
  352.     INDEX {applIndex, assocIndex}
  353.     ::= {assocTable 1}
  354.  
  355. AssocEntry ::= SEQUENCE {
  356.     assocIndex
  357.         INTEGER,
  358.     assocRemoteApplication
  359.         DisplayString,
  360.     assocApplicationProtocol
  361.         OBJECT IDENTIFIER,
  362.     assocApplicationType
  363.         INTEGER,
  364.     assocDuration
  365.         TimeTicks
  366. }
  367.  
  368. assocIndex OBJECT-TYPE
  369.     SYNTAX INTEGER (1..2147483647)
  370.     ACCESS read-only
  371.     STATUS mandatory
  372.     DESCRIPTION
  373.       "An index to uniquely identify each association for a network
  374.        service application."
  375.     ::= {assocEntry 1}
  376.  
  377. assocRemoteApplication OBJECT-TYPE
  378.     SYNTAX DisplayString
  379.     ACCESS read-only
  380.     STATUS mandatory
  381.     DESCRIPTION
  382.       "The name of the system running remote network service
  383.        application.  For an IP-based application this should be
  384.        either a domain name or IP address.  For an OSI application
  385.        it should be the string encoded distinguished name of the
  386.        managed object using the format defined in RFC-?.  For
  387.        X.400(84) MTAs which do not have a Distinguished Name, the
  388.        RFC-1327 syntax 'mta in globalid' should be used."
  389.     ::= {assocEntry 2}
  390.  
  391. assocApplicationProtocol OBJECT-TYPE
  392.     SYNTAX OBJECT IDENTIFIER
  393.     ACCESS read-only
  394.     STATUS mandatory
  395.     DESCRIPTION
  396.       "An identification of the protocol being used for the
  397.        application.  For an OSI Application, this will be the
  398.        Application Context.  For Internet applications, the IANA
  399.        maintains a registry of the OIDs which correspond
  400.        to well-known applications.  If the application protocol is
  401.        not listed in the registry, the value {applProtoID port} is
  402.        used where 'port' corresponds to primary port being used by
  403.        the application."
  404.     ::= {assocEntry 3}
  405.  
  406. assocApplicationType OBJECT-TYPE
  407.     SYNTAX INTEGER {
  408.         ua-initiator(1),
  409.         ua-responder(2),
  410.         peer-initiator(3),
  411.         peer-responder(4) }
  412.     ACCESS read-only
  413.     STATUS mandatory
  414.     DESCRIPTION 
  415.       "Shows whether the remote application is a User Agent, or a
  416.        peer server, and whether the remote end is initiator or
  417.        responder."
  418.     ::= {assocEntry 4}
  419.  
  420. assocDuration OBJECT-TYPE
  421.     SYNTAX TimeTicks
  422.     ACCESS read-only
  423.     STATUS mandatory
  424.     DESCRIPTION
  425.       "The time that the association has been open."
  426.     ::= {assocEntry 5}
  427.  
  428. applProtoID OBJECT IDENTIFIER ::= {application-mib 3}
  429.  
  430. END
  431.  
  432. A means will be defined to allocate an object identifier to each TCP
  433. application.  This will be done in consultation with the IANA.
  434.  
  435. Expires: December 18, 1993
  436.  
  437.